Thread: reborn and jv-bots ?

Originally Posted by James

@own3mall, your idea is pretty good too, but yeah, I wouldn't know how to do something like that. Here is some code that may help get us started.

Code:

trace_t * myTrace;

if (myTrace.fraction == 1.0f && (myTrace.surfaceFlags | (SURF_WOOD|SURF_STONE|SURF_METAL|SURF_LADDER|SURF_FOLIAGE)) )

The code above checks whether or not we bumped into something with the above surface parameters. This is where we would then change the direction of the bot so he would move in a different direction.

That looks like C code... can I use that directly in a script? I don't think so? I'm still curious to know how Sor would suggest attacking this crazy idea...

AI doesn't work like that, James If the point is to make them smart, then I don't think we can afford to implement trial-and-error approaches.

Didn't I already divulge about how I would go about it? It was in another thread perhaps, like on a 3rd or 4th page.
Anyway, like I said before, it's simply not feasible (or even practical) to implement a pathfinding system based on navmeshes (like CS).

I'll have to redo the pathfinding system from scratch. The great advantage of this is that I can optimize and customize it however I see fit.
The second is, because I know how it works, I can automate the pathnode creation process (which is actually a lot more complicated than I make it sound).
I was already working on a script that gets pseudo-accurate dimensions from the map. But it was a lot of bloody work.

If Razo added the 'getmaxs' and 'getmins' commands to retrieve an object's setsize (like in Spearhead and Breakthrough) then I can probably get them like this:

Code:

 local.min = $world getmins;
local.max = $world getmaxs;

instead of using the 20KB script I have now to obtain them (guesses really) dynamically.
The radar mod, you were referring to, doesn't do anything like this. If you wish to use it on another map, you have to edit it.

Anyway, each pathnode will be linked to another (thus all distances or 'costs' are determined beforehand) and they will be grouped
with one another (basically, once I get the dimensions, I can start dividing the map into sectors and link nodes to a given sector).
Both methods will greatly optimize the pathfinding logic. Secondly, the algorithm itself must be optimized and adapted for this mod.

As one of the last measures, paths are generated with a queue through parallel processing. Or rather, as 'parallel' as a computer can
process. So if bots A, B and C all have a new destination and need to know how to get there, they are put in the pathfinding queue.
The queue will go over each bot and find the next pathnode for each individual bot.

At this point they can start moving even though they don't know the full path. The queue will continue finding a new node per
bot in this fashion until all current path requests are handled.

This is just pathfinding though. The other approach will be used for combat, unblocking and dynamic obstacles. In this way we have a second problem.
If a bot 'wants' something (say... ammo or health or killing a blissfully unaware enemy) it will need to call the pathfinding engine again
to find a path from it to the healthbox or ammobox trigger in the game.

In this case, we have no choice but implement the pathfinding and moving system in such a way that a bot can switch from one path to another path without
actually terminating its progress. Unless of course we don't want bots who are smart enough to pick up some nearby health while it is on its way towards
another location.

But if a bot goes out of its way to pick up a healthbox, usually he'll just walk back (i.e. secondary path is reversed) to its last position on its primary path
so it can continue. This may look funny at times. The alternative is that the bot discards the path towards the health and requests another secondary path
to the nearest node on its primary path.

It's all these subtleties you'll have to take into account when you want smart bots and a speedy mod. It's best to do this beforehand (which is why I know
so thoroughly how I would handle the project, since I have been thinking about it a lot for quite some time now) and take it into account in the initial design.
Alternatively, you could design the mod such that it will be easy to add such things if it is deemed necessary.

EDIT: oh and James, despite the singleplayer AI being overridden (did you see this trick already in version 3, own3mall?), we're still using actors so the game
will make sure the bots won't walk through walls or fall through the floor etc...

Because bots are blind, essentially. They only see what we tell them they're seeing. Therefore if I were to send out bots and instruct them:

Code:

 if obstable
                 move randomly until no obstacle

This not only makes the bot look like a blind man looking for his glasses, but the programmer is no longer 'in control of' the bot's movement.

This approach is more suitable for a real-live AI project where you let a robot explore its surroundings or something (still impressive to behold though).
For gaming this is absurd, the sheer amount of complex calculations that needs to be done at the bots 'clock pulse' is staggering. That's why,
when it comes to something we already know, we can just tell the bots where everything is. We tell them, there are these objects or indicators
everywhere that they can use to navigate so they can move with certainty.

Only if this navigation fails or is deemed inadequate for a specific task, will the complex, more costful but more intelligent and flexible movement algorithms
(like you described, because in essence that's exactly what jv is doing in that huge loop in anim.scr) be used. You see, this type is perfect for evasive actions,
maneuvering...etc... because they are short distance (which simply means we'll encounter less problems). I think you can imagine how difficult it would to
tell a bot to 'go to vector B' when it only knows that 'vector B is in that direction'. For all it knows, vector B might not even specify a coordinate that the
bot can possibly reach.

In singleplayer all AI movement is based on pathnodes. While they probably randomized it in this sense:

Code:

 give AI#8 task:'patrol'
            addroute 'r1'
            addroute 'r2'
            ...

So the bot can randomly choose between one, but he will 'patrol' them in the exact same manner, again and again,
unless something happens where he must react (like an enemy showing up). Singleplayer pathnodes are baked
in the bsp. The engine's animation logic extends into scripts (pak0/anim/) and the animation defs in the tiki files.

This means the AI engine is largely hardcoded. But by giving 'Actor' class entities a player model, we disconnect the Actor
from the game's logic but are still able to use Actor commands and properties on them. The downside is error spam in the
console about emotions or facial expressions or something but once this is done, they won't try to interact with the game world anymore.

Q3 doesn't have 'smart' bots per se, but at the time, I can imagine, it was considered awesome. The reason for this:
http://fabiensanglard.net/quake3/a.i.php
In other words, they rushed it. AI is completely different from other software design because there is no 'right way' to do it.
There's only a bad way and a better way. For example, I've been looking at neural networks and perhaps I could employ them
with a two or three-layer perceptron so bots will be able to filter their input and their priorities more like humans do by estimating
and learning from situations. To get back to what you described, the only way it could work is via neural networks so the bot
can learn from all the bumping into stuff or all the traces. But that will require even more brainpower, more memory and more CPU.
Nonetheless, such a thing would be quite impressive apart from the fact that you'll have to make the bots remember what they've
learned because if you restart the map, you'll be back at square one.

Oh, I don't know if you're familiar with the 'cube engine' or any game that uses said engine but those guys had it easy. The entire map or level consisted of thousands of cubes and one could easily give them a texture and make them solid etc...
so if you implemented bots in this environment, you'd just have to check all solid cubes and the bot will automatically know where every obstacle is, where it can roam and where it cannot.

EDIT: In the healthbox/ammo pickup problem I described earlier, I could probably weave this into the pathfinding. Since the pathfinding would do one node at a time, paths are constructed 'live' while the bot is moving,
so in that respect I could deliberately make the path do a little detour so the bot'll walk over some health (while taking into account how long it takes the bot to get there and how long before the health or ammo disappears).

Actually, I really think this proof of concept can produce results that would be much more acceptable than JV's bots without much effort. I've been looking over the code and experimenting with stuff... the bot AI is much better than before.

How can I detect if a bot is following a path node, and will it stop following the path node if it sees an enemy? How do I make a bot follow the closest pathnode to it's location? How do I make a bot move? How do I make a bot follow a path node?

Code:

if(self.botenemy){
    // An enemy has been detected 
    // Bot logic is here to handle attacking players / bots
}else{
      // If bot is not currently moving on a pathnode
      if(!self.movingOnPathNode){
        	// Make bot follow closest path node to origin
  		self.followpath = closestpathto(self.origin)
  		self.bot_target_viewangles[0] = 0.0
  		self.pose = level.bots.POSE_CROUCH
  		self.key_attack_primary = 0
  		self.key_reload = self.current_weapon.rounds_in_clip < 0.7 * self.current_weapon.clipsize
  		self.key_jump = 0
  		self.key_lean = 0
      }
}

Really, all this POC needs are good path nodes, bomb handling logic, and fighting handling skills (which it already has). When a bot has completed following a path, make it follow a new one?

Didn't I already mention what needs to be done for the pathfinding? Use A* and optimize the hell out of it.
In addition you'll need logic that links adjacent nodes together (and you'll have to take height difference, obstacles etc... into account),
then you will need to write the moving logic, which will be tricky, because this is where you're fusing both movement approaches
and handling those pesky obstacles.

If I understand it correctly, apart from the random jumping, leaning and strafing, your bots won't be any smarter than the original jv_bots.

The thing is, making the bots able to move is all good but where will they move to? And what will they do once they get there? What will
they do if they encounter an enemy? What will they do when they encounter multiple enemies? Shoot the closest? Or shoot the one who
is a clearer threat (this means taking weapon, distance, canseeme, hasenemy etc.. into account)?

What is A*?

For simplicity, why not make each bot target a specific random player or bot? When a bot sees an enemy, it engages in combat. If it kills that enemy, it should again begin moving towards the original target it selected... until that target dies... then a new one is picked.

I'm not sure why this code doesn't work... probably because runto isn't a command. I wish it were this simple:

Code:

  if(self.botenemy){
    // An enemy has been detected 
    // Bot logic is here to handle attacking players / bots
  }else{
      self.botmovedir = (0 0 0)
      // Get random number
      if(level.randInt[self.entnum] == NULL){
        level.randInt[self.entnum] = randomint(1)                                       
        if(level.randInt[self.entnum] != NULL && level.randInt[self.entnum] == 0){
          // random player
          if(level.randPlayer[self.entnum] == NULL){
            level.randPlayer[self.entnum] = $player[randomint($player.size) + 1]  
            while(level.randPlayer[self.entnum] != NULL && isAlive $player[level.randPlayer[self.entnum]] ){
              self runto $player[level.randPlayer[self.entnum]] 
              waitframe
            }
            // player is dead... reset vars
            level.randPlayer[self.entnum] = NULL;
            level.randInt[self.entnum] = NULL;
          }
        }else if(level.randInt[self.entnum] != NULL && level.randInt[self.entnum] == 1){
          // random bot 
          local.rBot = randomint($bot3.size) + 1;
          while(local.rBot == self.entnum){
            local.rBot = randomint($bot3.size) + 1; 
            waitframe
          }
          if(level.randPlayer[self.entnum] == NULL){
            level.randPlayer[self.entnum] = $bot3[local.rBot]
            while(level.randPlayer[self.entnum] != NULL && isAlive $bot3[level.randPlayer[self.entnum]] ){
              self runto $bot3[level.randPlayer[self.entnum]] 
              waitframe
            }
            // bot is dead... reset vars
            level.randPlayer[self.entnum] = NULL;
            level.randInt[self.entnum] = NULL;
          }
          
        }
    		self.bot_target_viewangles[0] = 0.0
        /*
    	  self.pose = level.bots.POSE_CROUCH
    		self.key_attack_primary = 0
    		self.key_reload = self.current_weapon.rounds_in_clip < 0.7 * self.current_weapon.clipsize
    		self.key_jump = 0
    		self.key_lean = 0
        */
      }
  }

AI is hard to understand. I might download the Q3 source code and take a look. But even then, it's not helpful since MOHAA uses the UberTools. The bot source for Q3 uses C.

I learned that Star Trek: Elite Force 2 runs the same engine as MOHAA and also uses the UberTools. Unfortunately, it too codes the bots using C. I was hoping to just rip bot scripts from that game into this one, as the bots are built in for multiplayer in Star Trek Elite Force 2.... why can't this damn engine run straight c code anyways... or can it?